Danny Amor's Online Library

home *** CD-ROM | disk | FTP | other *** search

/ Danny Amor's Online Library / Danny Amor's Online Library - Volume 1.iso / html / rfc / rfcxxx / rfc767 < prev next >

Wrap

Text File | 1995-07-25 | 58.6 KB | 2,380 lines

RFC:767 A STRUCTURED FORMAT FOR TRANSMISSION OF MULTI-MEDIA DOCUMENTS Jonathan B. Postel August 1980 Information Sciences Institute University of Southern California 4676 Admiralty Way Marina del Rey, California 90291 (213) 822-1511 < INC-PROJECT, MMMSFS.NLS.21, >, 5-Sep-80 20:19 JBP ;;;; Postel August 1980 A Structured Format for Transmission of Multi-Media Documents TABLE OF CONTENTS PREFACE ........................................................ iii 1. INTRODUCTION ..................................................... 1 1.1. Motivation ................................................... 1 1.2. Scope ........................................................ 1 1.3. Terminology .................................................. 1 1.4. Document Description ......................................... 2 1.5. Other Work ................................................... 2 2. SPECIFICATION .................................................... 3 2.1. Document ..................................................... 3 2.2. Message Objects ............................................. 5 2.3. Body Structures ............................................. 13 2.3.1. Simple Elements ........................................... 13 2.3.2. Structured Text ........................................... 13 2.3.3. NLS File Example .......................................... 13 2.3.4. Multimedia Structures ..................................... 15 2.3.5. The Media ................................................. 21 2.3.6. TEXT ...................................................... 22 2.3.7. VOICE ..................................................... 22 2.3.8. FACSIMILE ................................................. 23 2.3.9. GRAPHICS .................................................. 24 3. EXAMPLES & SCENARIOS ............................................ 25 Example 1: Text Example .......................................... 25 Example 2: Multimedia Example .................................... 28 REFERENCES .......................................................... 31 Postel [Page i] August 1980 A Structured Format for Transmission of Multi-Media Documents [Page ii] Postel August 1980 A Structured Format for Transmission of Multi-Media Documents PREFACE This is the first edition of this format specification and should be treated as a request for comments, advice, and suggestions. A great deal of prior work has been done on computer aided message systems and some of this is listed in the reference section. This specification was shaped by many discussions with members of the ARPA research community, and others interested in the development of computer aided message systems. This document was prepared as part of the ARPA sponsored Internetwork Concepts Research Project at ISI. Jon Postel Postel [Page iii] August 1980 A Structured Format for Transmission of Multi-Media Documents Postel [Page iv] RFC: 767 J. Postel USC-ISI August 1980 A STRUCTURED FORMAT FOR TRANSMISSION OF MULTI-MEDIA DOCUMENTS 1. INTRODUCTION This document describes a format for transmitting structured data representations of multimedia documents. This format is intended to be used with the Internet Message Protocol in an internetwork message delivery system. That system is designed to transmit messages between processes in host computers called Message Processing Modules (MPMs). MPMs are located in several networks and together constitute an internetwork message delivery system. The Internet Message Protocol defines a message as being composed of an Identification, a Command, and a Document. This report is intended to define the format of such Documents. The reader is assumed to be familiar with the Internet Message Protocol [1]. 1.1. Motivation Computer applications are being implemented which interact with users in a variety of media (text, graphics, facsimile, speech). As computer devices become available to process multimedia information it becomes desirable to use computers to exchange multimedia information between programs and users via various mechanisms including computer mail. 1.2. Scope This format is intended to be used for the transmission of multimedia documents in the internetwork message delivery system, but it is thought that it has a wider applicability. 1.3. Terminology The messages are routed by a process called the Message Processing Module or MPM. Messages are created and consumed by User Interface Programs (UIPs) in conjunction with users. The basic unit transferred between MPMs is called a message. A message is made up of a transaction identifier (which uniquely identifies the message), a command (which contains the necessary information for delivery), and document. The document is a data structure. For a personal letter the document body corresponds to the contents of Postel [Page 1] August 1980 A Structured Format for Transmission of Multi-Media Documents Introduction the letter; the document header corresponds to the date line, greeting, and signature. For an inter-office memo the document body corresponds to the text; the document header corresponds to the header of the memo. The commands correspond to the information used by the Post Office or the mail room to route the letter or memo. Some of the information in the command is supplied by the UIP. 1.4. Document Description The document is composed of fields. Each field will carry an identifying name. Typical fields are DATE, TO, SUBJECT, and BODY. Most of the fields will be very simple, some will be complex. The body field may be quite complex. For example, the DATE is a very constrained character string specifying the date and time in ISO format. A more complex example is the TO field which is a list of mailboxes, where a mailbox is itself a property list of address information items. The BODY may be simply a character string, or a very structured collection of data representing information in different media. The BODY may be structured to indicate a controlled presentation of multimedia information. There is provision for the inclusion of text, graphics, facsimile, and voice information in the body of documents. The presentation of information units may sequential, independent, or simultaneous. 1.5. Other Work This protocol the benefited from the earlier work on message protocols in the ARPA Network [2,3,4,5,6], and the ideas of others about the design of computer message systems [7,8,9,10,11,12,13,14,15,16,17,18]. [Page 2] Postel August 1980 A Structured Format for Transmission of Multi-Media Documents 2. SPECIFICATION The structured format of a document is built on the basic data elements used in the Internet Message Protocol [1]. 2.1. Document The document is a property list of <name,value> pairs called fields. A few fields are specifically required and many are optional. Some of the field values are simple and a few are quite complicated. In particular the body value may be highly structured. Older message systems have considered the document to be divided into a header and a body, and have used keywords to indicate specific header fields (e.g., date, to, subject). Roughly speaking, this functionality is provided in this new structured format by considering the name part of the <name,value> pair to be a keyword. In addition, this new structured format eliminates the separate treatment of the body. It is impossible to foresee the many forms documents will take so the standard for a document header must be flexible. The approach here is to define a set of basic fields and allow addition of whatever fields are necessary. Features added in this fashion may not be understood by others. The minimum document is a property list of the following fields: Name Value ---- ----- DATE date string (name) SENDER a mailbox SUBJECT subject string (text) BODY a data structure A typical document is a property list containing the following fields: Name Value ---- ----- DATE date string (name) SENDER a mailbox FROM list of mailboxes TO list of mailboxes CC list of mailboxes SUBJECT subject string (text) BODY a data structure Postel [Page 3] August 1980 A Structured Format for Transmission of Multi-Media Documents Specification An elaborate document might contain the following fields: Name Value ---- ----- DATE date string (name) SENDER a mailbox FROM list of mailboxes TO list of mailboxes CC list of mailboxes BCC list of mailboxes REPLY-TO list of mailboxes SUBJECT subject string (text) COMMENTS comment string (text) MESSAGE-ID message identifier of this message (text) IN-REPLY-TO message identifier of previous message (text) REFERENCES message identifiers of other messages (text) KEYWORDS key terms used in this message (text) BODY a data structure One of the key objects is the mailbox. It appears in the sender, from, to, cc, bcc, and reply-to fields. The mailbox is a property list of objects that combine to specify a destination recipient for a message. Most of the <name,value> pairs that make up a mailbox are identical to those used in the deliver command in the Internet Message Protocol [1]. A few additional <name,value> pairs are defined for use in a mailbox in the document context. In particular, there is a field for the real name of a person in contrast to the "user name" which identifies a computer account. In addition there is a field to specify a distribution group name. Such group names are used to indicate that a document is being sent to a group of recipients. This essentially presents an alternate form for a mailbox which consists of the single <name,value> pair for the group name. There is no required relationship between a group name mailbox and other mailboxes in the same list. For example, all of the following situations are allowed: . a mailbox list consisting of a single mailbox specifying a particular user, . a mailbox list consisting of a single mailbox with a group name, . a mailbox list consisting of a mailbox with a group name and a mailbox specifying a particular user, with either the user in or not in the group, . a mailbox list consisting of a mailbox with a group name and a [Page 4] Postel August 1980 A Structured Format for Transmission of Multi-Media Documents Specification several mailboxes specifying a particular users, with some users in the group and some not, . a mailbox list consisting of several mailboxes specifying group names and a several mailboxes specifying a particular users, with some users in the groups and some not. 2.2. Message Objects In the documents of messages, we use a set of objects such as mailbox or date. These objects are encoded in basic data elements. Some objects are simple things like integers or character strings, other objects are more complex things like lists or property lists. The following is a list of the objects used in messages. The object descriptions are in alphabetical order. Account The account information. Represented by a name element. Address Address is intended to contain the minimum information necessary to identify a user, and no more (compare with mailbox). An address is a property list which contains the following <name,value> pairs: name description ---- ----------- NET network name HOST host name USER user name or: name description ---- ----------- MPM mpm-identifier USER user name Answer A yes (true) or no (false) answer to a question. Represented by a boolean element. Postel [Page 5] August 1980 A Structured Format for Transmission of Multi-Media Documents Specification BCC A list of mailboxes. The addresses of those who receive "blind carbon copies" of the message. Body A data structure. This may be as simple as a character string (represented by a name or text element), or complex structure of lists. It may be encrypted in part or in whole. Section 3.3 describes some possible structured bodies. C A character. Represented by a name element. CC A list of mailboxes. When copies of a message are sent to others in addition to the addresses in the To object, those to whom the copies are sent will have their addresses recorded here. City A city. Represented by a name element. Comments A comment string. Represented by a text element. Count A count of items of some sort. Represented by a integer element. Country A country. Represented by a name element. [Page 6] Postel August 1980 A Structured Format for Transmission of Multi-Media Documents Specification Date The date and time are represented according to the International Standards Organization (ISO) recommendations [19,20,21]. Taken together the ISO recommendations 2014, 3307, and 4031 result in the following representation of the date and time: yyyy-mm-dd-hh:mm:ss,fff+hh:mm Where yyyy is the four-digit year, mm is the two-digit month, dd is the two-digit day, hh is the two-digit hour in 24 hour time, mm is the two-digit minute, ss is the two-digit second, and fff is the decimal fraction of the second. To this basic date and time is appended the offset from Greenwich as plus or minus hh hours and mm minutes. The time is local time and the offset is the difference between local time and Coordinated Universal Time (UTC). To convert from local time to UTC algebraically subtract the offset from the local time. For example, when the time in Los Angeles is 14:25:00-08:00 the UTC is 22:25:00 or when the time in Paris is 11:43:00+01:00 the UTC is 10:43:00 Device A device name. Represented by a name element. Document A property list of fields. Distribution Group An distribution group is a property list which contains the following <name,value> pair: name description ---- ----------- GROUP document distribution group name This construct is used so that a distribution group will be a special case of a mailbox. Postel [Page 7] August 1980 A Structured Format for Transmission of Multi-Media Documents Specification Facsimile Structure A facsimile data structure. Represented by a property list. File A file name. Represented by a name element. Format A format indicator. Represented by a name element. From A list of mailboxes. The From is the name of the author of a document. Graphics Structure A graphics data structure. Represented by a property list. Group A document distribution group name. Represented by a name element. Host A host name. Represented by a name element. Ident The identifier of a person, usually their initials. Represented by a name element. In-Reply-To The message identifier of previous message. Represented by a text element. Internet Address This identifies a host in the ARPA internetwork environment. The internet address is a 32 bit number, the higher order 8 bits identify the network, and the lower order 24 bits identify the host on that network [22]. For use in this format the internet address is divided into eight bit fields and the value of each field is represented in decimal digits. For example, the ARPANET address of ISIE is 167837748 and is represented as 10,1,0,52. Further, this [Page 8] Postel August 1980 A Structured Format for Transmission of Multi-Media Documents Specification representation may be extended to include an address within a host, such as the TCP port of an MPM, for example, 10,1,0,52,0,45. Keywords The key terms used in this message. Represented by a text element. Mailbox This is the destination address of a user of the internetwork mail system. Mailbox contains information such as network, host, location, and local user identifier of the recipient of the message. The mailbox may contain information in addition to the minimum required for delivery. As an example, when one sends a message to someone for the first time, he may include many items to aid in identifying the correct recipient. However, once he gets a reply to this message, the reply will contain an Address (as opposed to Mailbox) which may be used from then on. A mailbox is a property list. A mailbox might contain the following <name,value> pairs: name description ---- ----------- MPM mpm-identifier NET network name HOST host name PORT address of MPM within the host USER user name (computer account name) PERSON the real name of a person GROUP document distribution group ORG organization name CITY city STATE state COUNTRY country ZIP zip code PHONE phone number The minimum mail box is an Address or a Distribution Group. Message-ID The message identifier of this message. This is not related to the MPM message identification, but is a UIP long term document identifier. Represented by a text element. Postel [Page 9] August 1980 A Structured Format for Transmission of Multi-Media Documents Specification MPM-Identifier The internetwork address of an MPM. This may be the ARPA Internet Address or an X.121 Public Data Network Address [23]. The mpm-identifier is a property list which has one <name,value> pair. This unusual structure is used so that it will be easy to determine the type of address used. Net A network name. Represented by a name element. NLS Block The information in an NLS node. Represented by a property list. NLS Node An NLS block and substructure. Represented by a property list. NLS Substructure A list of NLS nodes. Represented by a list. Org An organization name. Represented by a name element. Paragraph A paragraph of text. Represented by a text element. Parcel The basic unit of voice data. Represented by a bitstr element. Person The real name of a person. Represented by a name element. Password A password. Represented by a name element. Phone A phone number. Represented by a name element. [Page 10] Postel August 1980 A Structured Format for Transmission of Multi-Media Documents Specification Pointer A pointer to information stored outside this data structure. A property list containing the information necessary to locate the external data, the information necessary to gain access to the external data, and the information necessary to apply the correct interpretation to the external data. For example, this might include: name description ---- ----------- NET network name HOST host name FILE file name USER user name (computer account name) PASSWORD password ACCOUNT account FORMAT format Port The address of MPM within the host. Represented by a name element. Presentation Descriptor A property list of <name,value> pairs, where the name is an order indicator, and the value is a presentation element. The order indicators are SEQUENTIAL, SIMULTANEOUS, and INDEPENDENT. Presentation Element A property list of media structures. Protocol The name of the coding scheme used for a medium. Represented by a name element. References The message identifiers of other messages. Represented by a list of text elements. Reply-To A list of mailboxes. Sometimes it will be desired to direct the replies of a message to some address other than the from or the sender. In such a case the reply-to object can be used. Postel [Page 11] August 1980 A Structured Format for Transmission of Multi-Media Documents Specification R 450 Block The unit of Rapicom 450 data (585 bits). Represented by a bitstr element. Sender A mailbox. The sender will contain the address of the individual who sent the message. In some cases this is NOT the same as the author of the message. Under such a condition, the author should be specified in the from object. SID An NLS statement indetifier. Represented by a integer element. State A state name. Represented by a name element. Subject The subject of the message. Represented by a text element. Text Structure A text data structure. Represented by a property list. To A list of mailboxes. To identifies the addressees of the message. User A user name (computer account name). Represented by a name element. Version A version number. Represented by a index element. Vocoder A vocoder name. Represented by a name element. Voice Structure A voice data structure. Represented by a property list. [Page 12] Postel August 1980 A Structured Format for Transmission of Multi-Media Documents Specification X121 Address This identifies a host in the Public Data Network environment. When used as a part of identifier, it identifies the originating host of a message. The X121 address is a sequence of up to 14 digits [23]. For use in this format the X121 address is represented in decimal digits. ZIP A zip code. Represented by a name element. 2.3. Body Structures 2.3.1. Simple Elements The body could simply be a single data element. For example a single text element can represent a lengthy character string. <body> := TEXT or text:"this is the actual text of the body" 2.3.2. Structured Text The body could be thought of as paragraphs, where each paragraph is represented by a text element. The paragraphs are then the elements of a list. <body> := LIST (<paragraph>, <paragraph>, ...) <paragraph> := TEXT or list:(text:"paragraph one", text:"paragraph two", ...) 2.3.3. NLS File Example It is possible to represent the data from NLS files in this format. NLS is a large multipurpose system which operates on structured data files. The files are tree structured, and there is data associated with each node of the tree. There are several fields associated with each node as well. Postel [Page 13] August 1980 A Structured Format for Transmission of Multi-Media Documents Specification An NLS file is: proplist( file name:"FILENAME", name:<file> name of file name:"CREATION-DATE", name:<date> creation date and time name:"VERSION", index:<version> file version number name:"SID-COUNT", integer<count> current SID count name:"LAST-WRITER", name:<ident> last writer of file name:"OWNER", name:<ident> owner of file name:"LAST-WRITE-TIME", name:<date> last write date and time name:"LEFT-NAME-DELIM-DEFAULT", name:<c> default name name:"RIGHT-NAME-DELIM-DEFAULT", name:<c> delimiters name:"SUBSTRUCTURE", <nls-substructure> substructure )endlist An NLS substructure is: list:( substructure <nls-node> node is defined below . . . )endlist An NLS node is: proplist:( node name:"BLOCK", <nls-block> block defined below name:"SUBSTRUCTURE", <nls-substructure> substructure )endlist An NLS block is: proplist:( block name:"LEFT-NAME-DELIM", name:<c> left name delimiter name:"RIGHT-NAME-DELIM", name:<c> right name delimiter name:"SID", integer:<sid> SID number name:"CREATOR", name:<ident> statement creator name:"CREATION-TIME", name:<date> creation date and time name:"DATA", <data> data defined below )endlist [Page 14] Postel August 1980 A Structured Format for Transmission of Multi-Media Documents Specification NLS data is: proplist:( data name:"<a data name>", <type depends on data name> . . . . . . )endlist For text, data is: proplist:( data name:"TEXT", text:"text of statement" text )endlist 2.3.4. Multimedia Structures One can conceive of graphical information being displayed along with a running commentary, much as seminars use slides. A slide and its description are tied together. The coordination of such a presentation is central to its understanding. This synchronization should be captured within the document structure. There are three fundamentally different types of time ordered control which are needed within the document structure. These are: Simultaneous Sequential Independent Simultaneous data is intended for synchronous presentation. The implication is that this data is presented in parallel. Sequential data items will be presented one at a time, in the order listed. The ordering is strictly left to right. Independent data can be presented in any time order. It is not ordered in any manner. The data is brokethe user-PI, C, sets up TELNET connections with both server-PI's. One of the servers, say A, is then sent a PASV command telling him to "listen" on his data port rather than initiate a connection when he receives a transfer service command. When the user-PI receives an acknowledgment to the PASV command, which includes the identity of the host and port being listened on, the user-PI then sends A's port, a, to B in a PORT command; a reply is returned. The user-PI may then send the corresponding service commands to A and B. Server B initiates the connection and the transfer proceeds. The command-reply sequence is listed below where the messages are vertically synchronous but horizontally asynchronous: User-PI - Server A User-PI - Server B ------------------ ------------------ C->A : Connect C->B : Connect C->A : PASV A->C : 227 Entering Passive Mode. A1,A2,A3,A4,a1,a2 C->B : PORT A1,A2,A3,A4,a1,a2 B->C : 200 Okay C->A : STOR C->B : RETR B->A : Connect to HOST-A, PORT-a The data connection shall be closed by the server under the conditions described in the Section on Establishing Data Connections. If the server wishes to close the connection after a transfer where it is not required, he should do so immediately after the file transfer is completed. He should not wait until after a new transfer command is received because the user-process will have already tested the data connection to see if it needs to do a "listen"; (recall that the user must "listen" on a closed data port BEFORE sending the transfer request). To prevent a race condition here, the server sends a reply (226) after closing the data connection (or if the connection is left open, a "file transfer completed" reply (250) and the user-PI should wait for one of these replies before issuing a new transfer command. 41 June 1980 IEN 149 File Transfer Protocol RFC 765 COMMANDS The commands are TELNET character string transmitted over the TELNET connections as described in the Section on FTP Commands. The command functions and semantics are described in the Section on Access Control Commands, Transfer Parameter Commands, FTP Service Commands, and Miscellaneous Commands. The command syntax is specified here. The commands begin with a command code followed by an argument field. The command codes are four or fewer alphabetic characters. Upper and lower case alphabetic characters are to be treated identically. Thus any of the following may represent the retrieve command: RETR Retr retr ReTr rETr This also applies to any symbols representing parameter values, such as A or a for ASCII TYPE. The command codes and the argument fields are separated by one or more spaces. The argument field consists of a variable length character string ending with the character sequence <CRLF> (Carriage Return, Linefeed) for NVT-ASCII representation; for other negotiated languages a different end of line character might be used. It should be noted that the server is to take NO action until the end of line code is received. The syntax is specified below in NVT-ASCII. All characters in the argument field are ASCII characters including any ASCII represented decimal integers. Square brackets denote an optional argument field. If the option is not taken, the appropriate default is implied. 42 IEN 149 June 1980 RFC 765 File Transfer Protocol The following are the FTP commands: USER <SP> <username> <CRLF> PASS <SP> <password> <CRLF> ACCT <SP> <account information> <CRLF> REIN <CRLF> QUIT <CRLF> PORT <SP> <Host-port> <CRLF> PASV <CRLF> TYPE <SP> <type code> <CRLF> STRU <SP> <structure code> <CRLF> MODE <SP> <mode code> <CRLF> RETR <SP> <pathname> <CRLF> STOR <SP> <pathname> <CRLF> APPE <SP> <pathname> <CRLF> MLFL [<SP> <ident>] <CRLF> MAIL [<SP> <ident>] <CRLF> MSND [<SP> <ident>] <CRLF> MSOM [<SP> <ident>] <CRLF> MSAM [<SP> <ident>] <CRLF> MRSQ [<SP> <scheme>] <CRLF> MRCP <SP> <ident> <CRLF> ALLO <SP> <decimal integer> [<SP> R <SP> <decimal integer>] <CRLF> REST <SP> <marker> <CRLF> RNFR <SP> <pathname> <CRLF> RNTO <SP> <pathname> <CRLF> ABOR <CRLF> DELE <SP> <pathname> <CRLF> CWD <SP> <pathname> <CRLF> LIST [<SP> <pathname>] <CRLF> NLST [<SP> <pathname>] <CRLF> SITE <SP> <string> <CRLF> STAT [<SP> <pathname>] <CRLF> HELP [<SP> <string>] <CRLF> NOOP <CRLF> 43 June 1980 IEN 149 File Transfer Protocol RFC 765 The syntax of the above argument fields (using BNF notation where applicable ) is: <username> ::= <string> <password> ::= <string> <account information> ::= <string> <string> ::= <char> | <char><string> <char> ::= any of the 128 ASCII characters except <CR> and <LF> <marker> ::= <pr string> <pr string> ::= <pr char> | <pr char><pr string> <pr char> ::= printable characters, any ASCII code 33 through 126 <byte size> ::= any decimal integer 1 through 255 <Host-port> ::= <Host-number>,<Port-number> <Host-number> ::= <number>,<number>,<number>,<number> <Port-number> ::= <number>,<number> <number> ::= any decimal integer 0 through 255 <ident> ::= <string> <scheme> ::= R | T | ? <form code> ::= N | T | C <type code> ::= A [<SP> <form code>] | E [<SP> <form code>] | I | L <SP> <byte size> <structure code> ::= F | R | P <mode code> ::= S | B | C <pathname> ::= <string> 44 IEN 149 June 1980 RFC 765 File Transfer Protocol SEQUENCING OF COMMANDS AND REPLIES The communication between the user and server is intended to be an alternating dialogue. As such, the user issues an FTP command and the server responds with a prompt primary reply. The user should wait for this initial primary success or failure response before sending further commands. Certain commands require a second reply for which the user should also wait. These replies may, for example, report on the progress or completion of file transfer or the closing of the data connection. They are secondary replies to file transfer commands. One important group of informational replies is the connection greetings. Under normal circumstances, a server will send a 220 reply, "awaiting input", when the connection is completed. The user should wait for this greeting message before sending any commands. If the server is unable to accept input right away, he should send a 120 "expected delay" reply immediately and a 220 reply when ready. The user will then know not to hang up if there is a delay. The table below lists alternative success and failure replies for each command. These must be strictly adhered to; a server may substitute text in the replies, but the meaning and action implied by the code numbers and by the specific command reply sequence cannot be altered. Command-Reply Sequences In this section, the command-reply sequence is presented. Each command is listed with its possible replies; command groups are listed together. Preliminary replies are listed first (with their succeeding replies indented and under them), then positive and negative completion, and finally intermediary replies with the remaining commands from the sequence following. This listing forms the basis for the state diagrams, which will be presented separately. Connection Establishment 120 220 220 421 45 June 1980 IEN 149 File Transfer Protocol RFC 765 Login USER 230 530 500, 501, 421 331, 332 PASS 230 202 530 500, 501, 503, 421 332 ACCT 230 202 530 500, 501, 503, 421 Logout QUIT 221 500 REIN 120 220 220 421 500, 502 Transfer parameters PORT 200 500, 501, 421, 530 PASV 227 500, 501, 502, 421, 530 MODE, TYPE, STRU 200 500, 501, 504, 421, 530 File action commands ALLO 200 202 500, 501, 504, 421, 530 REST 500, 501, 502, 421, 530 350 46 IEN 149 June 1980 RFC 765 File Transfer Protocol STOR 125, 150 (110) 226, 250 425, 426, 451, 551, 552 532, 450, 452, 553 500, 501, 421, 530 RETR 125, 150 (110) 226, 250 425, 426, 451 450, 550 500, 501, 421, 530 LIST, NLST 125, 150 226, 250 425, 426, 451 450 500, 501, 502, 421, 530 APPE 125, 150 (110) 226, 250 425, 426, 451, 551, 552 532, 450, 550, 452, 553 500, 501, 502, 421, 530 MLFL 125, 150, 151, 152 226, 250 425, 426, 451, 552 532, 450, 550, 452, 553 500, 501, 502, 421, 530 RNFR 450, 550 500, 501, 502, 421, 530 350 RNTO 250 532, 553 500, 501, 502, 503, 421, 530 DELE, CWD 250 450, 550 500, 501, 502, 421, 530 47 June 1980 IEN 149 File Transfer Protocol RFC 765 ABOR 225, 226 500, 501, 502, 421 MAIL, MSND 151, 152 354 250 451, 552 354 250 451, 552 450, 550, 452, 553 500, 501, 502, 421, 530 MSOM, MSAM 119, 151, 152 354 250 451, 552 354 250 451, 552 450, 550, 452, 553 500, 501, 502, 421, 530 MRSQ 200, 215 500, 501, 502, 421, 530 MRCP 151, 152 200 200 450, 550, 452, 553 500, 501, 502, 503, 421 Informational commands STAT 211, 212, 213 450 500, 501, 502, 421, 530 HELP 211, 214 500, 501, 502, 421 Miscellaneous commands SITE 200 202 500, 501, 530 48 IEN 149 June 1980 RFC 765 File Transfer Protocol NOOP 200 500 421 49 June 1980 IEN 149 File Transfer Protocol RFC 765 STATE DIAGRAMS Here we present state diagrams for a very simple minded FTP implementation. Only the first digit of the reply codes is used. There is one state diagram for each group of FTP commands or command sequences. The command groupings were determined by constructing a model for each command then collecting together the commands with structurally identical models. For each command or command sequence there are three possible outcomes: success (S), failure (F), and error (E). In the state diagrams below we use the symbol B for "begin", and the symbol W for "wait for reply". We first present the diagram that represents the largest group of FTP commands: 1,3 +---+ ----------->| E | | +---+ | +---+ cmd +---+ 2 +---+ | B |---------->| W |---------->| S | +---+ +---+ +---+ | | 4,5 +---+ ----------->| F | +---+ This diagram models the commands: ABOR, ALLO, DELE, CWD, HELP, MODE, MRCP, MRSQ, NOOP, PASV, QUIT, SITE, PORT, STAT, STRU, TYPE. 50 IEN 149 June 1980 RFC 765 File Transfer Protocol The other large group of commands is represented by a very similar diagram: 3 +---+ ----------->| E | | +---+ | +---+ cmd +---+ 2 +---+ | B |---------->| W |---------->| S | +---+ --->+---+ +---+ | | | | | | 4,5 +---+ | 1 | ----------->| F | ----- +---+ This diagram models the commands: APPE, LIST, MLFL, NLST, REIN, RETR, STOR. Note that this second model could also be used to represent the first group of commands, the only difference being that in the first group the 100 series replies are unexpected and therefore treated as error, while the second group expects (some may require) 100 series replies. The remaining diagrams model command sequences, perhaps the simplest of these is the rename sequence: +---+ RNFR +---+ 1,2 +---+ | B |---------->| W |---------->| E | +---+ +---+ -->+---+ | | | 3 | | 4,5 | -------------- ------ | | | | +---+ | ------------->| S | | | 1,3 | | +---+ | 2| -------- | | | | V | | | +---+ RNTO +---+ 4,5 ----->+---+ | |---------->| W |---------->| F | +---+ +---+ +---+ 51 June 1980 IEN 149 File Transfer Protocol RFC 765 A very similar diagram models the Mail and Send commands: ---- 1 | | +---+ cmd -->+---+ 2 +---+ | B |---------->| W |---------->| E | +---+ +---+ -->+---+ | | | 3 | | 4,5 | -------------- ------ | | | | +---+ | ------------->| S | | | 1,3 | | +---+ | 2| -------- | | | | V | | | +---+ text +---+ 4,5 ----->+---+ | |---------->| W |---------->| F | +---+ +---+ +---+ This diagram models the commands: MAIL, MSND, MSOM, MSAM. Note that the "text" here is a series of lines sent from the user to the server with no response expected until the last line is sent, recall that the last line must consist only of a single period. 52 IEN 149 June 1980 RFC 765 File Transfer Protocol The next diagram is a simple model of the Restart command: +---+ REST +---+ 1,2 +---+ | B |---------->| W |---------->| E | +---+ +---+ -->+---+ | | | 3 | | 4,5 | -------------- ------ | | | | +---+ | ------------->| S | | | 3 | | +---+ | 2| -------- | | | | V | | | +---+ cmd +---+ 4,5 ----->+---+ | |---------->| W |---------->| F | +---+ -->+---+ +---+ | | | 1 | ------ Where "cmd" is APPE, STOR, RETR, or MLFL. We note that the above three models are similar, in fact the Mail diagram and the Rename diagram are structurally identical. The Restart differs from the other two only in the treatment of 100 series replies at the second stage. 53 June 1980 IEN 149 File Transfer Protocol RFC 765 The most complicated diagram is for the Login sequence: 1 +---+ USER +---+------------->+---+ | B |---------->| W | 2 ---->| E | +---+ +---+------ | -->+---+ | | | | | 3 | | 4,5 | | | -------------- ----- | | | | | | | | | | | | | | --------- | | 1| | | | V | | | | +---+ PASS +---+ 2 | ------>+---+ | |---------->| W |------------->| S | +---+ +---+ ---------->+---+ | | | | | 3 | |4,5| | | -------------- -------- | | | | | | | | | | | | ----------- | 1,3| | | | V | 2| | | +---+ ACCT +---+-- | ----->+---+ | |---------->| W | 4,5 -------->| F | +---+ +---+------------->+---+ 54 IEN 149 June 1980 RFC 765 File Transfer Protocol Finally we present a generalized diagram that could be used to model the command and reply interchange: ------------------------------------ | | Begin | | | V | | +---+ cmd +---+ 2 +---+ | -->| |------->| |---------->| | | | | | W | | S |-----| -->| | -->| |----- | | | | +---+ | +---+ 4,5 | +---+ | | | | | | | | | | | 1| |3 | +---+ | | | | | | | | | | | | ---- | ---->| F |----- | | | | | | | | +---+ ------------------- | | V End 55 June 1980 IEN 149 File Transfer Protocol RFC 765 TYPICAL FTP SCENARIO User at Host U wanting to transfer files to/from Host S: In general the user will communicate to the server via a mediating user-FTP process. The following may be a typical scenario. The user-FTP prompts are shown in parentheses, '---->' represents commands from Host U to Host S, and '<----' represents replies from Host S to Host U. LOCAL COMMANDS BY USER ACTION INVOLVED ftp (host) multics<CR> Connect to Host S, port L, establishing TELNET connections <---- 220 Service ready <CRLF> username Doe <CR> USER Doe<CRLF>----> <---- 331 User name ok, need password<CRLF> password mumble <CR> PASS mumble<CRLF>----> <---- 230 User logged in.<CRLF> retrieve (local type) ASCII<CR> (local pathname) test 1 <CR> User-FTP opens local file in ASCII. (for.pathname) test.pl1<CR> RETR test.pl1<CRLF> ----> <---- 150 File status okay; about to open data connection Server makes data connection to port U <CRLF> <---- 226 Closing data connection, file transfer successful<CRLF> type Image<CR> TYPE I<CRLF> ----> <---- 200 Command OK<CRLF> store (local type) image<CR> (local pathname) file dump<CR> User-FTP opens local file in Image. (for.pathname) >udd>cn>fd<CR> STOR >udd>cn>fd<CRLF> ----> <---- 450 Access denied<CRLF> terminate QUIT <CRLF> ----> Server closes all connections. 56 IEN 149 June 1980 RFC 765 File Transfer Protocol CONNECTION ESTABLISHMENT The FTP control connection is established via TCP between the user process port U and the server process port L. This protocol is assigned the service port 21 (25 octal), that is L=21. 57 June 1980 IEN 149 File Transfer Protocol RFC 765 APPENDIX ON MAIL The basic commands transmitting mail are the MAIL and the MLFL commands. These commands cause the transmitted data to be entered into the recipients mailbox. MAIL <SP> <recipient name> <CRLF> If accepted, returns 354 reply and considers all succeeding lines to be the message text, terminated by a line containing only a period, upon which a 250 completion reply is returned. Various errors are possible. MLFL <SP> <recipient name> <CRLF> If accepted, acts like a STOR command, except that the data is considered to be the message text. Various errors are possible. There are two possible preliminary replies that a server may use to indicate that it is accepting mail for a user whose mailbox is not at that server. 151 User not local; Will forward to <user>@<host>. This reply indicates that the server knows the user's mailbox is on another host and will take responsibility for forwarding the mail to that host. For example, at BBN (or ISI) there are several host which each have a list of many of the users on several of the host. These hosts then can accept mail for any user on their list and forward it to the correct host. 152 User Unknown; Mail will be forwarded by the operator. This reply indicates that the host does not recognize the user name, but that it will accept the mail and have the operator attempt to deliver it. This is useful if the user name is misspelled, but may be a disservice if the mail is really undeliverable. Three FTP commands provide for "sending" a message to a logged-in user's terminal, as well as variants for mailing it normally whether the user is logged in or not. 58 IEN 149 June 1980 RFC 765 File Transfer Protocol MSND -- SeND to tnguage," TM-80-18, USC/Information Sciences Institute, July 1980. [30] Graphics Standard Planning Committee, "Core System," Computer Graphics, V. 13, N. 3, SIGGRAPH, ACM, August 1979. Postel [Page 33] August 1980 A Structured Format for Transmission of Multi-Media Documents [Page 34] Postel